Skip to content

Infrastructure for lints during attribute parsing, specifically duplicate usages of attributes #138164

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Jun 12, 2025

Conversation

jdonszelmann
Copy link
Contributor

@jdonszelmann jdonszelmann commented Mar 7, 2025

r? @oli-obk

This PR adds a new field to OwnerInfo to buffer lints which are generated during attribute parsing and ast lowering in general. They can't be emitted at this stage because at that point there's no HIR yet, and early lints are already emitted.

This also adds the generic S: Stage to attribute parsers. Currently we don't emit any lints during early attribute parsing, but if we ever want to that logic will be different. That's because there we don't have hir ids yet, while at the same time still having access to node ids and early lints. Even though that logic isn't completely there in this PR (no worries, we don't use it), that's why the parameter is there.

With this PR, we also add 2 associated consts to SingleAttributeParser. Those determine what logic should be applied when finding a duplicate attribute.

This PR was getting pretty large, so the first code using this logic is in #138165. This code is all new things that weren't possible before so it also doesn't break any behaviour. However, some of it will be dead code right now. I recommend reviewing both before merging, though in some sense that doubles the size of the review again, and the other PR might be more controversial. Let me know how you want to do this @oli-obk

@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 7, 2025
@rustbot
Copy link
Collaborator

rustbot commented Mar 7, 2025

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

@rustbot rustbot added has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 7, 2025
@rustbot

This comment has been minimized.

@jdonszelmann
Copy link
Contributor Author

(am aware of merge commits, was just an easy way to get those changes in before they're on master so we can run CI on this PR. will obviously remove once those changes are on master and this PR can be merged)

@rust-log-analyzer

This comment has been minimized.

@jdonszelmann jdonszelmann force-pushed the attr-parsing-lint-infra branch from b5f1130 to 9559a37 Compare March 8, 2025 19:03
@rustbot rustbot removed has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 8, 2025
@rust-log-analyzer

This comment has been minimized.

@jdonszelmann jdonszelmann force-pushed the attr-parsing-lint-infra branch from 9559a37 to d529827 Compare March 9, 2025 15:31
@rust-log-analyzer

This comment has been minimized.

@jdonszelmann jdonszelmann force-pushed the attr-parsing-lint-infra branch from d529827 to bfeed70 Compare March 9, 2025 16:08
@rust-log-analyzer

This comment has been minimized.

@jdonszelmann jdonszelmann force-pushed the attr-parsing-lint-infra branch from bfeed70 to fc63551 Compare March 9, 2025 20:08
@bors
Copy link
Collaborator

bors commented Mar 12, 2025

☔ The latest upstream changes (presumably #138388) made this pull request unmergeable. Please resolve the merge conflicts.

@oli-obk oli-obk added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 20, 2025
@jdonszelmann jdonszelmann force-pushed the attr-parsing-lint-infra branch 2 times, most recently from 2be9ade to 57ee80c Compare June 9, 2025 22:40
@jdonszelmann
Copy link
Contributor Author

@rustbot review

@rustbot rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 9, 2025
@jdonszelmann jdonszelmann force-pushed the attr-parsing-lint-infra branch from 92205a2 to e2afe04 Compare June 12, 2025 08:02
@jdonszelmann
Copy link
Contributor Author

@bors r=oli_obk

@bors
Copy link
Collaborator

bors commented Jun 12, 2025

📌 Commit e2afe04 has been approved by oli_obk

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 12, 2025
@fmease
Copy link
Member

fmease commented Jun 12, 2025

@bors r=oli-obk

@bors
Copy link
Collaborator

bors commented Jun 12, 2025

💡 This pull request was already approved, no need to approve it again.

@bors
Copy link
Collaborator

bors commented Jun 12, 2025

📌 Commit e2afe04 has been approved by oli-obk

It is now in the queue for this repository.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 12, 2025
…ra, r=oli-obk

Infrastructure for lints during attribute parsing, specifically duplicate usages of attributes

r? `@oli-obk`

This PR adds a new field to OwnerInfo to buffer lints which are generated during attribute parsing and ast lowering in general. They can't be emitted at this stage because at that point there's no HIR yet, and early lints are already emitted.

This also adds the generic `S: Stage` to attribute parsers. Currently we don't emit any lints during early attribute parsing, but if we ever want to that logic will be different. That's because there we don't have hir ids yet, while at the same time still having access to node ids and early lints. Even though that logic isn't completely there in this PR (no worries, we don't use it), that's why the parameter is there.

With this PR, we also add 2 associated consts  to `SingleAttributeParser`. Those determine what logic should be applied when finding a duplicate attribute.

This PR was getting pretty large, so the first code using this logic is in rust-lang#138165. This code is all new things that weren't possible before so it also doesn't break any behaviour. However, some of it will be dead code right now. I recommend reviewing both before merging, though in some sense that doubles the size of the review again, and the other PR might be more controversial. Let me know how you want to do this `@oli-obk`
bors added a commit that referenced this pull request Jun 12, 2025
Rollup of 10 pull requests

Successful merges:

 - #134536 (Lint on fn pointers comparisons in external macros)
 - #138164 (Infrastructure for lints during attribute parsing, specifically duplicate usages of attributes)
 - #141069 (Suggest mut when possbile for temporary value dropped while borrowed)
 - #141934 (resolve: Tweak `private_macro_use` lint to be compatible with upcoming macro prelude changes)
 - #142034 (Detect method not being present that is present in other tuple types)
 - #142402 (chore(doctest): Remove redundant blank lines)
 - #142406 (Note when enum variants shadow an associated function)
 - #142407 (Remove bootstrap adhoc group)
 - #142408 (Add myself (WaffleLapkin) to review rotation)
 - #142418 (Remove lower_arg_ty as all callers were passing `None`)

r? `@ghost`
`@rustbot` modify labels: rollup
@workingjubilee
Copy link
Member

There are several open PRs touching adjacent areas that will conflict with this, and there is somewhat-timing-sensitive work that is strictly blocked on this. Bumping its priority accordingly.

@bors p=1 rollup=iffy

@workingjubilee
Copy link
Member

( Ideally it just lands in the rollup currently trying to land though. )

@bors
Copy link
Collaborator

bors commented Jun 12, 2025

⌛ Testing commit e2afe04 with merge 573a015...

@jdonszelmann
Copy link
Contributor Author

jdonszelmann commented Jun 12, 2025

@workingjubilee I'm happy this gets merged but some of those I deliberately didn't r+ yet to wait for this one but this makes sure it work :)

@bors
Copy link
Collaborator

bors commented Jun 12, 2025

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 573a015 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 12, 2025
@bors bors merged commit 573a015 into rust-lang:master Jun 12, 2025
11 checks passed
@rustbot rustbot added this to the 1.89.0 milestone Jun 12, 2025
Copy link
Contributor

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 6c8138d (parent) -> 573a015 (this PR)

Test differences

Show 147 test diffs

Stage 1

  • session_diagnostics::verify_attr_parsing_empty_confusables_30: pass -> [missing] (J0)
  • session_diagnostics::verify_attr_parsing_empty_confusables_31: [missing] -> pass (J0)
  • session_diagnostics::verify_attr_parsing_repr_ident_31: pass -> [missing] (J0)
  • session_diagnostics::verify_attr_parsing_repr_ident_32: [missing] -> pass (J0)
  • session_diagnostics::verify_attr_parsing_stability_outside_std_29: pass -> [missing] (J0)
  • session_diagnostics::verify_attr_parsing_stability_outside_std_30: [missing] -> pass (J0)
  • session_diagnostics::verify_attr_parsing_unrecognized_repr_hint_32: pass -> [missing] (J0)
  • session_diagnostics::verify_attr_parsing_unrecognized_repr_hint_33: [missing] -> pass (J0)
  • session_diagnostics::verify_attr_parsing_unused_duplicate_29: [missing] -> pass (J0)

Additionally, 138 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 573a01569000d395498a5f98f916d6e5305ac81a --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. x86_64-apple-2: 5058.2s -> 6576.6s (30.0%)
  2. x86_64-apple-1: 7328.3s -> 9029.2s (23.2%)
  3. dist-x86_64-msvc-alt: 7179.2s -> 8838.4s (23.1%)
  4. dist-various-1: 4293.5s -> 4917.7s (14.5%)
  5. dist-x86_64-apple: 9693.9s -> 10934.9s (12.8%)
  6. dist-android: 2388.0s -> 2613.8s (9.5%)
  7. dist-apple-various: 6971.2s -> 6390.0s (-8.3%)
  8. dist-x86_64-solaris: 5465.3s -> 5020.7s (-8.1%)
  9. dist-aarch64-linux: 6155.9s -> 5682.4s (-7.7%)
  10. x86_64-mingw-1: 9148.9s -> 8527.6s (-6.8%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (573a015): comparison URL.

Overall result: ❌ regressions - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
0.5% [0.1%, 1.0%] 107
Regressions ❌
(secondary)
1.0% [0.1%, 3.1%] 56
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.5% [0.1%, 1.0%] 107

Max RSS (memory usage)

Results (primary 1.7%, secondary 3.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
1.7% [0.4%, 7.3%] 9
Regressions ❌
(secondary)
4.4% [1.0%, 13.6%] 9
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-8.5% [-8.5%, -8.5%] 1
All ❌✅ (primary) 1.7% [0.4%, 7.3%] 9

Cycles

Results (primary -1.0%, secondary 1.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
2.3% [1.6%, 2.7%] 6
Improvements ✅
(primary)
-1.0% [-1.0%, -1.0%] 1
Improvements ✅
(secondary)
-1.6% [-1.6%, -1.6%] 1
All ❌✅ (primary) -1.0% [-1.0%, -1.0%] 1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 754.987s -> 754.801s (-0.02%)
Artifact size: 372.08 MiB -> 372.21 MiB (0.03%)

@rustbot rustbot added the perf-regression Performance regression. label Jun 13, 2025
bors added a commit that referenced this pull request Jun 13, 2025
…-perf-problems, r=<try>

collect delayed lints in hir_crate_items

r? `@oli-obk`

Attempt to mitigate perf problems in #138164
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants